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Lessons  Learned  in  Iraq 

Operations  Enduring/Iraqi  Freedom 

•  Showed  that  interdependency  and  interoperability 
reduce  sensing-to-decision-to-engagement  time 

•  Confirmed  that  Military  Transformation  is  on  the  right 
track 

That  “lessons  from  fighting  insurgents  [are]  mostly  negative,” 
also  confirms  the  need  for  Continued  Transformation. 

Loren  B.  Thompson,  Lexington  Institute  Georgetown  University,  November  18,  2003 

Continuing  Transformation  must  cast  a  more  comprehensive 
net  for  a  Future  Army  more  adapted  to  its  ecology. 
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Lessons  Learned  for  Transformation 

Lessons  for  Transformation  include: 

•  Clearly  identifying  the  enemy  by  new  emphasis  on  intelligence , 
cultural  sensitivity  and  information  processing. 

•  Countering  an  enemy’s  adaptability  to  technologies  by 
spiraling  in  refinements/replacements  across  doctrine, 
organizations,  training,  acquisition,  personnel  and  facilities. 

•  Preparing  for  new  forms  of  military  conflict  using  modular 
organizational  constructs  networked  to  fit  very  different 
situations. 

•  Utilizing  the  criticality  of  the  network  by  conducting  information 
operations  that  both  exploit  it  and  keep  it  secure. 


Adapted  from  “The  Army  in  2020”  White  Paper  by  John  M.  Riggs 
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The  Future  Army  will  be  Network  Centric 

The  Army  is  becoming  Network  Centric  as  networks  become 
more  the  center  of  attention. 

As  this  continues,  everything  the  Army  does  will  be  Network 
Centric,  including  its: 

•  Operations 

•  Doctrine 

•  Organizations 

•  Training,  Leaders  and  Education 

•  Personnel 

•  Facilities 

•  Acquisition 

The  Future  will  have  a  Joint,  Network  Centric  “mindset.” 

Adopted  from  “The  Army  in  2020”  White  Paper  by  LTG  John  M.  Riggs 
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Network  Centrism 

Being  Network  Centric  is 

•  taking  the  form  of  complex  system  that  puts  networks 
center  stage 

•  based  on  both  military  and  commercial  development  and 
use  of  communication,  information  and  network 
technologies 

•  derived  from  experience  of  developing/using  the  Internet. 

Nodes  in  network  centric  systems  are: 

•  relatively  autonomous  and  can  act  rapidly  and  effectively 

•  almost  always  networks  themselves 

•  constrained  by  their  place  in  the  network. 
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What  is  Network  Centric  Warfare? 


NCW  is  the  application  of  a  networked  force  to  achieve  a  decisive  warfighting 
advantage. 

NCW  translates  information  superiority  into  superior  combat  power. 

Characterized  by: 

•  effectively  linking  friendly  forces  against  enemy  forces 

•  shared  awareness  between  decision  makers  and  soldiers 

•  increased  speed  of  command 

•  More  discrete  control  over  tempo  of  operations 

•  greater  force  effectiveness 

•  increased  adaptability  (as  a  complex  adaptive  system) 

•  a  degree  of  self-synchronization  or  self  organization. 

Controlled  by: 

•  Body  of  doctrine  to  support  the  actions 

•  Communication  among  subunits  facilitating  self-organizing 

•  Clear  commander’s  intent  sensitive  to  both  negative  and  positive  feed-back 

Arthur  K.  Cebrowski,  Network  Centric  Warfare,  Military  Technology,  MILTEC  5/2003 
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How  is  NCW  Doing  -  In  Iraq 

What  can  be  learned: 

•  The  war  is  not  over.  Lessons  will  look  a  lot  different  depending  on  outcomes. 

•  Many  significant  lessons  will  remain  secret. 

•  Review  process  may  be  subject  to  Transformation  bias  and  other  perspective  bias. 

Lessons  up  to  now  are  that  some  capabilities  were: 

•  high  performing  -  joint  integration/adaptive  planning,  joint  force  synergy,  special 
ops  integration  (SATCOM,  ADOCS) 

•  effective  but  need  improvement  -  urban  operations,  ISR  (SBIRS,  Global  Hawk, 
JSTARS,  ABCS  effective  in  command  centers  but  not  always  for  troops) 

•  not  up  to  expectations  or  needs  -  fratricide  prevention,  deployment  planning  and 
execution,  reserve  mobilization,  troops  often  missing  visual  displays  (SIGINT) 

Since  conventional  combat  ended,  U.S.  forces  have  faced  growing 
guerrilla  resistance  -  lessons  mostly  negative. 

Iraq  experience  validates  Cebrowski  view  that  networked  warfare 
isn’t  just  about  technology. 

See  “Lessons  of  Iraq,”  by  Loren  B.  Thompson,  Lexington  Institute,  11/03 

Joint  Forces  Command  Study,  8/03 
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What  is  Network  Centric  Acquisition 

Network  Centric  Acquisition  can... 

•  avoid  redundant  costs  by  supporting  achievement  of  commonality 

•  facilitate  interoperability 

•  provide  resources  and  infrastructure  for  evolutionary  upgrades 

•  shorten  response  times  to  provide  technology  when  under  threat 

•  ensure  preparedness  by  designing  industrial  base  partnerships 

...by  leveraging  communication,  information  and  network 
technologies  to: 

•  design  and  enter  into  new  partnerships  -  services,  industrial  base  and 
multi-national 

•  capture  experience  and  information  that  can  be  turned  into  actionable 
knowledge  both 

-  internally  through  organizational  learning  and  experience  factories 

-  Inter-organizationally  via  joint  risk  management  and  libraries  of 
reusable  software. 

See  “Network-Centric  Acquisition:  The  Key  to  Joint  Warfighting,”  by  R.A.  Lefande,  DAU  PM  2002 
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Can  Current  Acquisition  Achieve  NCA 

Challenge  from  VADM  Cebrowski  (Director  of  DoD’s  Force 
Transformation):  “The  operational  side  is  agile,  adaptive  and  high 
speed;  whereas  the  acquisition  side  is  very  ponderous,  not  agile,  time 
lines  are  long  and  response  problematic.”  ( Inside  the  Navy  11/02) 

Operational  Acquisition:  Soldiers  fighting  in  Operation  Enduring 
Freedom  identified  the  need  to  confront  underground  targets  through 
use  of  rapid  development  of  thermobaric  weapons  used  in  Afghanistan. 

Because  this  was  on  the  operational  side,  versions  of  the  weapon  were 
developed  and  delivered  quickly.  (Cebrowski,  Inside  the  Navy  11/02) 

Can  the  Acquisition  Side  Deliver? 


©  2003  by  Carnegie  Mellon  University 


page  10 


Carnegie  Mellon 

Software  Engineering  Institute 


Other  NCA  Issues 

NCA  has  many  issues  in  common  with  acquiring  Complex 
System  of  Systems  (CSOS) 

(Boehm  and  Basili,  (Complex  System  of  Systems  -  CSOS,  SIS  Acquisition  Conference,  2003). 

•  Does  managing  CSOS  projects  via  Lead  System  Integrators  (LSIs)  work? 

Little  experience  so  far  and  the  jury  is  not  in. 

Some  CSOS  have  been  tested,  successfully  fielded,  refined  and  evolved 
without  an  LSI  and  without  any  show-stopping  problems. 

•  Is  the  complexity  of  CSOS  manageable  by  standard  software  engineering 
practices? 

Conflict  between  and  number  of  quality  attributes  makes  tradeoff  analysis  very 
difficult. 

Number  of  and  interlinking  of  software  modules  makes  creating  and  changing 
the  software  and  the  software  architecture  very  difficult 

•  Is  there  something  to  learn  from  looking  at  CSOS  as  Complex  Adaptive 
Systems? 

Perhaps  they  are  amenable  to  a  degree  of  self  organization  involving  new, 
perhaps  more  open-ended,  forms  of  partnership. 
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Present  Acquisition  Structure  Issues 

The  goal  of  equipping  a  Joint  Force  to  prepare  for  NCW  is 
impeded  by: 

•  separated  Services  broken  down  into  Programs  and  PEOs 
specializing  in  particular  kinds  of  warfare  product  or  product  line 

-  usually  no  interoperability  across  products  within  a  PEO,  let  alone 
product  lines  within  and  across  PEOs  and  services 

-  redundancy  of  products  and  product  lines  across  Programs,  PEOs 
and  Services 

•  Congress’  insistence  on  the  auditable  separateness  of  the 
Programs  and  contract  awards  traced  to  their  districts. 
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Targeting  Software  to  Achieve  NCA 

Software 

•  has  no  production  phase  -  the  design,  development  and  documentation  of 
the  software  is  the  product 

•  can  insure  interoperability  but  is  also  the  primary  cause  of  failed 
interoperability 

•  is  redundantly  developed  at  the  subsystem  level,  and  this  is  tolerated  so 
that  risk  can  be  transferred  to  the  contactor. 

If  the  government  owns  the  design,  source  code  and  documentation 
resulting  from  the  development  of  the  software,  it  is  possible  to 

•  make  the  software  available  in  an  online  library  where  it  can  become 
standardized  for  reuse 

•  define  a  common  “what,  where  and  when”  standard  enabling  exchange  of 
this  type  of  data  with  any  other  system  that  makes  the  same  investment. 

See  “Network-Centric  Acquisition:  The  Key  to  Joint  Warfighting,”  by  R.A.  Lefande,  DAU  PM  2002 
See  “A  Few  Choice  Words  Can  Make  Network-Centric  Warfare  a  Reality  Today,”  by  Rich  Byrne  , 

www.afcea.org/signal 
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Software  Changes  the  Essence  of  Systems 

“Well  designed  and  implemented  software  can  be  changed  in 
minutes  or  hours  versus  the  weeks  and  months  required  for 
hardware  modification,  thus  permitting  flexibility  to  address  rapidly 
evolving  mission  requirements.” 

software  governs  most  of  the  interfaces  of  today's  systems 
[which  because  of]  [t]he  flexibility  of  software  enables  us  to  quickly 
integrate  separately  developed  systems  permitting  ...  horizontal 
integration  primarily  through  effective  software  application.” 

“...software  enables  systems  to  adapt  to  new  environments,  new 
threats,  and  new  concepts  of  operation.  This  adaptability  is  a  key 
enabler  to  reaping  the  benefits  of  rapid  technological  change  and 
providing  the  transformational  battlefield  envisioned  by  Joint  Vision 
2020”’ 

John  M.  Gilligan,  “Military  Use  Software,”  Department  of  the  Air  Force,  CrossTalk  01/04 
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SW  Intensive  Systems  Need  Discipline... 

The  flexibility  to 

•  address  rapidly  evolving  mission  requirements 

•  quickly  integrate  separately  developed  systems 

•  adapt  to  new  environments,  new  threats,  and  new  concepts  of 

operation  (John  M.  Gilligan,  CrossTalk  01/04) 

may  require  modification  of  discipline  to  fit  the  new  context. 
Otherwise, 

•  unrealistic  expectations  of  what  can  be  accomplished  through 
software  and  data  interoperability 

•  the  quickness  of  modifying  software  will  have  untoward  impacts 
on  architecture,  configuration  management  and  testing. 
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...  Even  a  New  Form  of  Discipline 

The  impact  of  software  on  complex  technology  systems  has 
not  been  sufficiently  understood  by  PMs,  Contractors  or  even 
the  Software  and  Systems  Engineering  disciplines. 

Software  is  not  simply  one  component  among  others. 

New  software  capabilities  and  discipline  have  to  be  integrated 
into  overall  systems  engineering  processes. 

What  is  needed  is  an  interdisciplinary  culture  of  software 
professionals  with  a  complex  software  intensive  system 
enterprise  perspective. 
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All  Complex  Technological  Systems  are 
Networks 

An  important  historical  lesson  is  that  all  complex 
technological  systems  can  be  described  as  networks. 

(see  Thomas  Hughes,  American  Genesis  and  also  Rescuing  Prometheus) 

Many  of  these  complex  technological  systems  have  been 
built  by  military  sponsored  or  supported  projects. 

Examples  from  World  War  II  and  after  are: 

•  Manhattan  Project 

•  SAGE 

•  Atlas 

•  ARPANET 
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Network  Centric  Systems  are  Software 
Intensive  Systems 

After  World  War  II,  complex  technological  systems  began  to  be  infused 
with  a  new  kind  of  technology,  software,  that  changed  the  essence  of 
systems. 

From  that  point  on,  complex  technological  systems  were  typically 
software  intensive  systems. 

Software  is  capable  of  networking  relatively  stand-alone  technical 
systems  into  systems  of  systems. 

Software  intensive  systems  support  linking  stand-alone  organizations 
into  networks  of  learning  enterprises  but  only  if  social  factors  are  central 
to  the  design. 

These  technical  and  social  networks  co-evolve  as  Network  Centric 
Systems  (NCSs). 

Perhaps  the  paradigm  of  a  network  centric/software  intensive  system 
(N  C/S  IS)  project  was  the  ARPANET. 
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ARPANET:  Network  Centric/Software  Intensive 

Packet  Switching 

•  ARPA-IPTO  -  sufficient  resources  in  the  60s  and  70s  to  provide  the 
necessary  “glue”  for  building,  operating  and  extending  the  Internet 

Layering  -  Communications  (IMPs  and  Routing),  Hosts, 

Applications  (email) 

•  Routing  was  self-adaptive  in  that  each  IMP  “decided”  independently 
where  to  send  packets  adapting  to  changes  in  network  configuration 
and  traffic. 

Development  (ARPA  supported  BBN,  UCLA,  NAC) 

•  Network  Working  Group’s  Requests  for  Comments  -  Body  of 
Knowledge  via  the  ARPANET  and  evolving  standards  informally 
(telnet,  ftp...) 

Deploy,  Operate  and  Refine  (Significant  User  Involvement) 
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ARPANET  1971 


MAP  4  September  1 971 
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ARPANET  Users 

Users  significantly  transformed  the  ARPANET 

•  Developed  alternative  terminal  interface  systems  which 
ARPA  began  to  fund. 

•  Replaced  resource  sharing  and  distributed  computing 
unexpectedly  with  email  as  the  service  of  choice. 

•  Created  tools  for  accounting  and  editing. 
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ARPANET  1980 


ARPANET  GEOGRAPHIC  MAP,  OCTOBER  1980 


0  PLUHIBU&TIP 
•  £30 

(NOTE:  THIS  WAP  DOES  NOT  $HOW  AftPA'S  EXPERIMENTAL  SATELLITE  CONNECTIONS) 
NAMES  SHOWN  ARE  IMP  NAMES,  NOT  (NECESSARILY)  HOST  NAMES 


item 
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Visualization  Study  of  the  NSFNET. 

Donna  Cox  and  Robert  Patterson  1992 
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The  ARPANET  Became  Part  of  the 
Social  Network  that  was  Creating  It 

Just  as  the  ARPANET  co-evolves  and  integrates 
with  the  network  using  and  building  it... 

...so  too  network  centric  technologies  co-evolve 
and  integrate  with  their  NCW  users... 

...and  other  network  centric  technologies  co¬ 
evolve  and  integrate  with  their  NCA  participants. 

Similarly,  NCW  has  to  co-evolve  and  integrate 
with  NCA. 
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ARPANET  and  Internet  Successes... 

Managing,  developing  and  using  the  ARPANET  (and  eventually 

the  Internet)  stemmed  from  and  extended  a  culture  that 

•  Avoided  the  sort  of  High  Control  that  imposes 

-  needless  layers  of  bureaucracy  that  interferes  with  the 
delivery  of  needed  capabilities 

-  elaborate  procedural  models  where  lighter-weight  methods 
can  be  applied 

•  Encouraged  Agile  Control  by  encouraging  new 

-forms  of  information-sharing,  communication  and 
participation 

-ways  of  forming  virtual  teams,  organizations  and  co¬ 
laboratories 

-  use  of  the  ARPANET  to  build  bodies  of  knowledge  (RFCs) 

-  approaches  of  evolving  standards  informally 
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...also  Brought  Potential  Failures... 

These  potential  failures  are  now  targeted  in  the  rise  of: 

•  a  security  industry  needed  for  network  survivability 

•  new  forms  of  software  engineering  to  handle  the 
immense  expectations  and  risks  of  networking  various 
weapons  and  C4I  capabilities  into  systems  of  systems 

•  a  large  literature  on  organizational  and  inter- 
organizational  learning  from  risk  and  failure. 
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Are  Networks  and  Communities  That 
Learn  from  Failure:  The  Key? 

Network  Centric  Systems  (NCSs)  like  other  innovative 
complex  technological  systems  grow  or  die  according  to 
how  well  they  address  repeated  failures. 

NCSs  may  fail  more  but  they  also  can  provide  more  timely 
and  sustained  support  for  learning  from  failure  and  making 
corrections. 

Responding  to  repeated  failures  requires  knowledge 
creating  communities  and  knowledge  networks. 

These  new  social  environments  of  joint  learning  can  be 
powerfully  supported  by  knowledge  bases  and  experience 
factories  of  failures,  successes,  risks  and  opportunities. 
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Boundary  Spanning  Learning 

Historians  of  technology  have  repeatedly  found  that  the  locus  of 
technological  knowledge  spans  across: 

•  Disciplines 

•  Organizations 

•  Policy  Makers 

•  Producers 

•  Users 
Examples  are: 

•  American  inventor  entrepreneurs  (like  Sperry  etc.)  who  used  patents 
as  indicators  of  open  problems  and  the  leading  edge  of  invention 

•  ARPANET  builders/users  who  participated  in  the  Network  Working 
Group  through  exchange  of  Requests  for  Comments  over  the 
ARAPANET 
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Inter-Organizational  Learning  and 
Knowledge  Networks 

•  Complex  technological  systems  like  the  ARPANET  are 
produced  by  projects. 

•  The  knowledge  created  in  these  complex  technological  projects 
is  often  disseminated  through  the  circulation  of  people. 

•  This  knowledge  can  be  more  durably  circulated  if  the  inter- 
organizational  partnerships  forged  in  the  projects  are 
maintained  through  longer  term  alliances. 

•  There  are  many  examples  of  such  knowledge  networks  or 
virtual  organizations  in  the  bio-technology  and 
computer/software  industry. 
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Taking  Steps  Toward  NCA 

“Integration  of  software  into  our  overall  system  engineering  processes 
requires  a  new  culture  with  a  strong  emphasis  on  training  and  education 
and  a  focus  on  the  integrated  enterprise  as  the  target  environment.  ” 

(John  M.  Gilligan,  Department  of  the  Air  Force). 

How  might  such  a  culture  of  more  durable  enterprise  knowledge 
be  built? 

By  combining, 

•  new  types  of  partnerships  with 

•  boundary  spanning  networks  and 

•  information  and  network  technologies 

durable  knowledge  networks  and  the  new  culture  could  result. 

It  might  therefore  be  feasible  and  beneficial  for  the  Army  if  the 
Army  Software  Systems  Improvement  Program  (ASS IP)  would 
help  create  such  an  Army  Knowledge  Network  (AKN). 
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ASSIP  Recent  History  and  Desired 
Outcomes 

•  Fall  of  2002  -  ASA(ALT)  agrees  with  SEI  to  execute  the 
Army  Software  Systems  Improvement  Plan  (ASSIP)]  with  a 
’02  -  ’09  target 

•  The  ASSIP  calls  for  - 

“Dramatically  Improving  the  Acquisition  of  Army  Software 
Intensive  Systems” 

•  Task  scope  is  Army  -  or  Enterprise-Wide 

•  ASSIP  calls  for: 

-  Inter-organizational  perspectives 

-  Virtual-organizational  applications 

-  Made  up  of  Army  Acquisition  community  components 
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The  Network  Structure  of  ASSIP 


Authority  Plan 


I  mplementation 

•  Policy 

•  Guidance 

m  •  Decisions  ($) 

J  •  Pilots 

-Training 
m  •  Metrics 

W  •  "Score  Card" 

^  •  Schedule 


{ 

{ 


•  Guidance 

•  Decisions  ($) 

•  I  nitiate  Pilot  Efforts 

•  Metrics 
•"Score  Card" 

•  I  nstitute  Best  Practices 

•  Process  I  improvements 

•  Other  Specific  I  mprovements 

•  Other  Specific  Activities 
•"Score  Card" 
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ASSIP  as  a  Learning  Enterprise: 

Scaffolding  for  a  Story  to  Come? 

•  ASSIP  concept  provides  an  executable  structure 

•  ASSIP  concept  is  identifying  a  set  of  acquisition 
“Benchmarks” 

•  ASSIP  concept  provides  a  forum  for  crafting  SIS 
acquisition  improvement 

•  ASSIP  structure  produces  an  actionable  plan  for  each 
FY 

•  ASSIP  responds  to  Section  804  guidance 
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The  Challenge  Remains 

•  The  Operational  components  of  the  DOD  are  embracing 
NOW  as  a  means  to  attain  the  goals  of  Joint  2020  through 
Transformation. 

•  The  Acquisition  components  of  the  DOD  should  consider 
the  potential  of  concepts  such  as  those  driving  NOW  and 
Transformation  to  attain  similar  goals. 

•  While  the  future  is  yet  to  be  realized,  work  is  beginning 
across  the  Services. 
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